최근에 시니어 개발자 대부분이 이직을 하면서 몇 가지 상황을 경험했다.
경험을 토대로 느끼는 생각을 정리해봤다.
자세
지금도 주니어지만, 완전 주니어 때는 시간이 더 걸리더라도 완벽하게 문제를 해결하는 것이 좋다고 생각했다. 돌아가더라도 원초적인 문제를 해결하는 것이 가장 빠르다고 믿기 때문이다. 그리고 그것은 실제로 대부분의 상황에서 적합했다.
하지만, 때로는 문제 상황이 시급하다면 Blocking을 해결하기 위해 ‘기술’보다 당장의 ‘문제’에 집중하는 것도 때로는 필요하다.
예를 들어, 배포 직전인데 A라는 문제가 발생했다. A라는 문제가 100% 해결될 것이라고는 장담할 수는 없지만, 시도는 해볼법한 방법이 있음에도 원초적인 문제의 원인을 찾아서 해결하고자 하는 행동이 가끔은 문제가 된다.
시간이 주어진다면 당연히 원초적인 문제를 찾아서 완벽하게 해결하는 것이 좋다. 하지만, 우리는 개발자 이전에 한명의 구성원이고 나의 Blocking이 동료의 Blocking으로 이어질 수 있다는 사실을 잊어서는 안된다.
소통
개발자는 의견을 내되, 그 의견이 시스템에 큰 문제를 일으키지 않는다면 지나치게 강조할 필요는 없다. 예를 들어 코드 컨벤션을 구축할 때 나의 생각을 전달하는 것은 중요하지만, 나의 의견을 잘 정리하고 상대방을 충분히 이해시켰음에도 반대 의견이 나온다면, 그 의견 또한 충분히 이해하고 협의점을 찾는 과정이 중요하다.
연차가 쌓일수록 개발자에게 소통의 중요성이 더 커진다고 느낀다. “개발자는 의견을 적극적으로 어필할 수 있어야 한다”는 말이 나만의 의견을 고집해야 한다는 뜻이 아님을 다시 한 번 되새길 필요가 있다. 타인의 의견 또한 존중하고 협의점을 찾는 과정이 중요하다.
좋은 소통 경험
컨벤션 회의에서 가장 클리어한 결과를 얻을 수 있었던 방법은 모두 의견을 적극적으로 얘기하다가 어떤 컨벤션 항목에 대해 확실하게 비선호라는 의견을 가진 사람이 있다면 그 의견을 존중하며 회의를 진행하는 것이었다.
중재자
1~2년차 때는 적극적으로 의견을 표명했다면 지금은 중재자 역할을 경험하고 있다. 회의의 중심에서 의견을 정리하는 것 또한 실력이었다.
서로의 의견이 ‘틀린’것이 아니고 ‘다르다’는 것을 이해시키고 생각이 너무 다른 부분에서는 일단 시도해보고 1주일 후에 다시 협의해보는 방향으로 회의를 이끌어갔다.